home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 2217 < prev    next >
Encoding:
Text File  |  1996-08-06  |  2.4 KB  |  56 lines
  1. Path: news.wright.edu!emoyer
  2. From: emoyer@cs.wright.edu (Eric Moyer)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Why use private class members instead of protected?
  5. Date: 16 Jan 1996 14:34:16 GMT
  6. Organization: Wright State University, Dayton, OH 45435
  7. Message-ID: <4dgd18$as0@mercury.wright.edu>
  8. References: <30F4AB49.6ABB@sierra.net> <30F50874.15FB7483@intellektik.informatik.th-darmstadt.de>
  9. NNTP-Posting-Host: gamma.cs.wright.edu
  10. X-Newsreader: TIN [version 1.2 PL2]
  11.  
  12. Enno Sandner (enno@intellektik.informatik.th-darmstadt.de) wrote:
  13. >TGColwell wrote:
  14. >> 
  15. >> I'm relatively new to c++.  I have one quick question:  If child
  16. >> classes can only access protected members of the parent class,
  17. >> why make any members of any class private?  Wouldn't it be
  18. >> better to make members of the parent class protected so that the
  19. >> class is alway "inheritance ready"?
  20. >No,
  21. >it's quite often a better approach to make these data-members private and
  22. >provide the suitable accessor functions. In this way you can change the
  23. >representation of the data-members without the problem that modifications
  24. >will 'propagate' downwards the class-hierarchy.
  25.  
  26. I agree.  However, there are still instances when one would make a data
  27. member protected.  In particular, very basic (as in linked list) classes
  28. with a stable representation should have protected data members.  Why?  For
  29. two reasons.
  30.  
  31.     1.  Being basic classes, they (and their derived classes) are likely to
  32.         be heavily used, especially in inner loops.  Even minor
  33.         optimizations, such as eliminating copying for an accessor function
  34.         would have benefits throughout your source code.
  35.  
  36.     2.  Since they have a stable, efficient representation, and have been
  37.         studied for years, the representation is unlikely to change and
  38.         cause problems throughout the class hierarchy.
  39.  
  40. Also, I like to declare functions protected rather than private. In
  41. particular, I declare many accessor/mutator functions as follows:
  42.  
  43. public:
  44.     DATA get_Data() const;
  45. protected:
  46.     //Returns FALSE on error 
  47.     //<BOOL and FALSE are macros allowing compiler independence>
  48.     BOOL set_Data(DATA const &d);
  49.  
  50. --Eric
  51. -- 
  52. -------------------------------------__|__-----------------------------------
  53. "A wise man once said nothing"         |        Emoyer@valhalla.cs.wright.edu
  54. ---------------------------------------| ------------------------------------
  55. GCS/M d(-+) p++@ c++++ l+ u++ e+(*) m++@ s+/ !n h--(*) f+ g+ w+++ t@ r+@ !y 
  56.